:bug: Add bundle-version and package-name annotations to CER phase objects by pedjak · Pull Request #2580 · operator-framework/operator-controller

pedjak · 2026-03-20T13:56:48Z

Description

When upgrading between bundle versions that produce identical Kubernetes
manifests, the installed version status was not updated because CER phases
were identical across versions, causing in-place patches instead of new
revision creation.

Propagate bundle-version and package-name annotations onto each rendered
object within CER phases so that different bundle versions always produce
distinct phases, triggering new revision creation via phase immutability.
As a side benefit, every applied bundle resource now carries two annotations
that immediately tell an observer which package and version it belongs to.

Changes

Propagate bundle-version and package-name annotations onto each rendered object within CER phases
Add e2e test catalog entry with identical bundle content at a different version (1.0.4)
Add e2e scenario verifying that upgrading between versions with identical manifests creates a new revision
Rename mergeLabelMaps to mergeStringMaps (now used for both labels and annotations)

Reviewer Checklist

API Go Documentation
Tests: Unit Tests (and E2E Tests, if appropriate)
Comprehensive Commit Messages
Links to related GitHub Issue(s)

When upgrading between bundle versions that produce identical Kubernetes manifests, the installed version status was not updated because CER phases were identical across versions, causing in-place patches instead of new revision creation. Propagate bundle-version and package-name annotations onto each rendered object within CER phases so that different bundle versions always produce distinct phases, triggering new revision creation via phase immutability. As a side benefit, every applied bundle resource now carries two annotations that immediately tell an observer which package and version it belongs to. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

netlify · 2026-03-20T13:56:54Z

✅ Deploy Preview for olmv1 ready!

Name	Link
🔨 Latest commit	`b18a28b`
🔍 Latest deploy log	https://app.netlify.com/projects/olmv1/deploys/69c404e63b165e00087b99a4
😎 Deploy Preview	https://deploy-preview-2580--olmv1.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

Copilot

Pull request overview

Propagates bundle metadata (package name + bundle version) onto each rendered object in ClusterExtensionRevision (CER) phases so that otherwise-identical manifests across bundle versions still produce distinct phases and trigger new revision creation (fixing installed version status not updating on upgrade).

Changes:

Add a new test bundle version (1.0.4) that reuses the exact same bundle image as 1.0.0 to reproduce the “identical manifests across versions” upgrade case.
Add an E2E update scenario that upgrades from 1.0.0 to 1.0.4.
Update revision generation to stamp olm.operatorframework.io/bundle-version and olm.operatorframework.io/package-name as annotations on each rendered object, with unit test updates.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 5 comments.

File	Description
testdata/images/catalogs/test-catalog/v1/configs/catalog.yaml	Adds a new bundle version (`1.0.4`) that points at the same image as `1.0.0` for regression testing identical renders across versions.
test/e2e/features/update.feature	Adds an E2E scenario upgrading to `1.0.4` to validate upgrade behavior when bundle content is identical.
internal/operator-controller/applier/boxcutter_test.go	Updates unit test expectations to include the new per-object annotations.
internal/operator-controller/applier/boxcutter.go	Implements propagation of bundle-version/package-name annotations onto each rendered object (Helm and non-Helm paths).

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

internal/operator-controller/applier/boxcutter.go

test/e2e/features/update.feature

internal/operator-controller/applier/boxcutter_test.go

codecov · 2026-03-20T14:32:29Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 67.84%. Comparing base (0db26d7) to head (e18ab88).
⚠️ Report is 4 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2580      +/-   ##
==========================================
+ Coverage   67.74%   67.84%   +0.10%     
==========================================
  Files         137      137              
  Lines        9560     9591      +31     
==========================================
+ Hits         6476     6507      +31     
  Misses       2585     2585              
  Partials      499      499

Flag	Coverage Δ
e2e	`38.15% <10.00%> (-0.02%)`	⬇️
experimental-e2e	`51.27% <65.00%> (+0.20%)`	⬆️
unit	`52.90% <92.50%> (+0.10%)`	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

internal/operator-controller/applier/boxcutter.go

joelanford · 2026-03-20T18:24:05Z

cc @grokspawn Should we be officially plumbing "release" everywhere that we plumb "version" now?

grokspawn · 2026-03-20T18:51:10Z

I think ideally we would think in terms of CompositeVersion. I'll take a look later.
We should also be able to rely on uniqueness from Bundle.VersionString or variations.

- Rename mergeLabelMaps to mergeStringMaps since it handles both labels and annotations - Only set bundle-version/package-name annotations when values are non-empty - Update unit test to use realistic revisionAnnotations values Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Copilot

Pull request overview

Copilot reviewed 12 out of 12 changed files in this pull request and generated 1 comment.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

internal/operator-controller/labels/labels.go

camilamacedo86

I am OK with the proposal.
/lgtm

tmshort · 2026-03-24T20:27:45Z

/hold
@grokspawn were there additional changes to be made here?

tmshort · 2026-03-24T20:29:58Z

/approve
@pedjak remove the hold if you get a response from @grokspawn

joelanford

Quick review of the implementation. All looks good to me except the one comment about putting Version and Release together in the BundleMetadata API/struct.

Will try to find time to review tests today if you need me to.

Can you review the Copilot reviews and address/resolve?

joelanford · 2026-03-25T11:12:11Z

internal/operator-controller/controllers/clusterextension_controller.go

 type RevisionMetadata struct {
 	RevisionName string
 	Package      string
+	Release      string


Do we need to put this in the BundleMetadata? Seems like it is something that is a very close sibling of Version.

Do we need to put this in the BundleMetadata? Seems like it is something that is a very close sibling of Version.

My understanding from
#2580 (comment)
is that we want to have it, so that we can propagate it on each of applied resources. If not, we can remove it.

I left a similar comment in my review. I feel that we will need to have another pass through this flow when we have consolidated the bundle version types down to a single one. At that point, I'd prefer to see that type consistently used with the exception of the clusterextension API itself (where we probably cannot adjust since it's GA).
But I didn't think we had to have it now. Once we merge operator-framework/operator-registry#1938 I think that we can adjust those types.

Do we need to put this in the BundleMetadata? Seems like it is something that is a very close sibling of Version.

After double checking not sure if we can - if add it to BundleMetadata this will also API/CRD change and that part of API is already GA. Let's keep it where it is for now until operator-framework/operator-registry#1938 merged or we address it in that PR.

Perhaps we should hold off on release plumbing in this PR then? And then @grokspawn will cover "plumb release everywhere that version already is plumbed" as its own effort?

grokspawn · 2026-03-25T13:44:38Z

internal/operator-controller/bundle/versionrelease.go


 type Release []bsemver.PRVersion

+// String returns the dot-separated string representation of the release segments.


We'll be pivoting away from this type to an equivalent type in op-reg, but they behave exactly the same so we don't have to do it right this minute.

grokspawn · 2026-03-25T13:50:09Z

internal/operator-controller/bundle/versionrelease_test.go

 	}
 }

+func TestRelease_String(t *testing.T) {


I initially was going to ask for add'l testing to align this properly with its origin, but this can come when we adopt the op-reg type.

grokspawn · 2026-03-25T14:02:27Z

internal/operator-controller/controllers/clusterextension_reconcile_steps.go

 			Image:   resolvedBundle.Image,
 			// TODO: Right now, operator-controller only supports registry+v1 bundles and has no concept
 			//   of a "release" field. If/when we add a release field concept or a new bundle format
 			//   we need to re-evaluate use of `AsLegacyRegistryV1Version` so that we avoid propagating


I think we need to have a larger conversation about the callflow here, but I think it's probably better to wait until we merge operator-framework/operator-registry#1938 and get the type adoption changes made. I was initially going to ask for changes here, but since this is more mature than that I think we can defer.

grokspawn · 2026-03-25T14:07:23Z

@joelanford I'm good with this effort. I'll let you release the hold when you have completed review.

pedjak · 2026-03-25T16:16:08Z

@grokspawn @joelanford revert the last commit, ptal

joelanford

/approve

openshift-ci · 2026-03-25T16:33:06Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: joelanford, tmshort

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

~~OWNERS~~ [joelanford,tmshort]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

joelanford · 2026-03-25T17:01:44Z

/hold cancel

Copilot AI review requested due to automatic review settings March 20, 2026 13:56

openshift-ci bot requested review from grokspawn and joelanford March 20, 2026 13:56

Copilot started reviewing on behalf of pedjak March 20, 2026 13:57 View session

Copilot AI reviewed Mar 20, 2026

View reviewed changes

pedjak requested review from camilamacedo86, dtfranz and perdasilva and removed request for grokspawn March 20, 2026 14:16

camilamacedo86 reviewed Mar 20, 2026

View reviewed changes

internal/operator-controller/applier/boxcutter.go Show resolved Hide resolved

jianzhangbjz mentioned this pull request Mar 23, 2026

🐛 Trigger Helm upgrade when storage labels change even if manifests are identical #2558

Closed

4 tasks

pedjak requested review from camilamacedo86 and Copilot March 23, 2026 12:42

Copilot started reviewing on behalf of pedjak March 24, 2026 13:27 View session

pedjak changed the title ~~🐛 Add bundle-version and package-name annotations to CER phase objects~~ 🐛 Add bundle-version, package-name, and bundle-release annotations to CER phase objects Mar 24, 2026

Copilot AI reviewed Mar 24, 2026

View reviewed changes

internal/operator-controller/labels/labels.go Outdated Show resolved Hide resolved

camilamacedo86 reviewed Mar 24, 2026

View reviewed changes

openshift-ci bot assigned camilamacedo86 Mar 24, 2026

openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Mar 24, 2026

openshift-ci bot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Mar 24, 2026

openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Mar 24, 2026

joelanford reviewed Mar 25, 2026

View reviewed changes

grokspawn reviewed Mar 25, 2026

View reviewed changes

pedjak force-pushed the OCPBUGS-78311/fix-cer-version-status branch from e18ab88 to b18a28b Compare March 25, 2026 15:53

openshift-ci bot removed the lgtm Indicates that a PR is ready to be merged. label Mar 25, 2026

pedjak changed the title ~~🐛 Add bundle-version, package-name, and bundle-release annotations to CER phase objects~~ 🐛 Add bundle-version and package-name annotations to CER phase objects Mar 25, 2026

joelanford approved these changes Mar 25, 2026

View reviewed changes

openshift-ci bot assigned joelanford Mar 25, 2026

openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Mar 25, 2026

openshift-ci bot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Mar 25, 2026

openshift-merge-bot bot merged commit d57c077 into operator-framework:main Mar 25, 2026
46 checks passed


		type Release []bsemver.PRVersion

		// String returns the dot-separated string representation of the release segments.

Conversation

pedjak commented Mar 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Changes

Reviewer Checklist

Uh oh!

netlify bot commented Mar 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Deploy Preview for olmv1 ready!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

codecov bot commented Mar 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Uh oh!

joelanford commented Mar 20, 2026

Uh oh!

grokspawn commented Mar 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

camilamacedo86 left a comment

Choose a reason for hiding this comment

Uh oh!

tmshort commented Mar 24, 2026

Uh oh!

tmshort commented Mar 24, 2026

Uh oh!

joelanford left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

grokspawn commented Mar 25, 2026

Uh oh!

pedjak commented Mar 25, 2026

Uh oh!

joelanford left a comment

Choose a reason for hiding this comment

Uh oh!

openshift-ci bot commented Mar 25, 2026

Uh oh!

joelanford commented Mar 25, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

pedjak commented Mar 20, 2026 •

edited

Loading

netlify bot commented Mar 20, 2026 •

edited

Loading

codecov bot commented Mar 20, 2026 •

edited

Loading

grokspawn commented Mar 20, 2026 •

edited

Loading